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Abstract 
This document describes the Lightweight Directory Access Protocol 
(LDAP) / X.500 ’entryDN’ operational attribute. The attribute 


provides a copy of the entry’s distinguished name for use in 
attribute value assertions. 
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1. Background and Intended Use 


In X.500 Directory Services [X.501], such as those accessible using 
the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry 
is identified by its distinguished name (DN) [RFC4512]. However, as 
an entry’s DN is not an attribute of the entry, it is not possible to 
perform attribute value assertions [RFC4511] against it. 


This document describes the ’entryDN’ operational attribute which 
holds a copy of the entry’s distinguished name. This attribute may 
be used in search filters. For instance, searching the subtree 
<dc=example,dc=com> with the filter: 


(entryDN: componentFilterMatch:=or: { 
item: { component "3", rule rdnMatch, value "ou=A" }, 
item: { component "3", rule rdnMatch, value "ou=B" } }) 


would return entries in the subtree <ou=A,dc=example,dc=com> and 
entries in subtree <ou=B,dc=example,dc=com>, but would not return any 
other entries in the subtree <dc=example,dc=com>. 


In the above paragraph, DNs are presented using the string 
representation defined in [RFC4514], and the example search filter is 
presented using the string representation defined in [RFC4515] with 
whitespace (line breaks and indentation) added to improve 
readability. The ’/componentFilterMatch’ and ’/rdnMatch’ rules are 
specified in [RFC3687]. 


Schema definitions are provided using LDAP description formats 
[RFC4512]. Definitions provided here are formatted (line wrapped) 
for readability. 


2. ‘’entryDN’ Operational Attribute 


The ’entryDN’ operational attribute provides a copy of the entry’s 
current DN. 


The following is an LDAP attribute type description suitable for 
publication in subschema subentries. 


( 1.3.6.1.1.20 NAME ’entryDN’ 
DESC ’DN of the entry’ 
EQUALITY distinguishedNameMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 
SINGLE-VALUE 
NO-USER-MODIFICATION 
USAGE directoryOperation ) 
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Note that the DN of the entry cannot be modified through this 
attribute. 


3. Security Considerations 


As this attribute only provides an additional mechanism to access an 
entry’s DN, the introduction of this attribute is not believed to 
introduce new security considerations. 


4. IANA Considerations 
4.1. Object Identifier Registration 


IANA has registered (upon Standards Action) an LDAP Object Identifier 
[RFC4520] for use in this document. 


Subject: Request for LDAP OID Registration 

Person & email address to contact for further information: 
Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 

Specification: RFC 5020 

Author/Change Controller: IESG 

Comments: 
Identifies the ’entryDN’ attribute type 


4.2. ‘entryDN’ Descriptor Registration 


IANA has registered (upon Standards Action) the LDAP ‘’entryDN’ 
descriptor [RFC4520]. 


Subject: Request for LDAP Descriptor Registration 

Descriptor (short name): entryDN 

Object Identifier: 1.3.6.1.1.20 

Person & email address to contact for further information: 
Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 

Usage: Attribute Type 

Specification: RFC 5020 

Author/Change Controller: IESG 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
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Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 
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